Bump OpenICF to 2.1.0-SNAPSHOT and fix CodeQL note-level findings - #259

…sses (#191)

## Summary

#134 replaced `Class.newInstance()` with `ReflectionUtil.newInstance()`,
which goes through `MethodHandles.Lookup.findConstructor`. That changed
how a connector configuration class with a missing dependency fails:

- **before:** `Class.newInstance()` threw `NoClassDefFoundError`. The
`catch (Exception)` in `createDefaultAPIConfiguration` let it through,
and `LocalConnectorInfoManagerImpl` (`catch (NoClassDefFoundError)`,
likewise the OSGi managers) skipped that connector and logged an error;
- **now:** `findConstructor` reports the same `NoClassDefFoundError` as
`IllegalAccessException: no such constructor`. That is an `Exception`,
so it is wrapped in a `ConnectorException` that nobody catches, and the
whole bundle scan fails.

Found through OpenIdentityPlatform/OpenIDM#259 (bump to openicf
2.1.0-SNAPSHOT): `ScriptedCRESTConfiguration` in `groovy-connector`
refers to `httpasyncclient`, which is not on the OpenIDM test classpath,
and `ConnectorInfoProviderServiceTest.beforeTest` fails with
`LocalManager initialisation failed`; 126 tests of the module are
skipped.

```
Caused by: ConnectorException: java.lang.IllegalAccessException: no such constructor: org.forgerock.openicf.connectors.scriptedcrest.ScriptedCRESTConfiguration.<init>()v
  at LocalConnectorInfoManagerImpl.createDefaultAPIConfiguration(LocalConnectorInfoManagerImpl.java:339)
Caused by: java.lang.NoClassDefFoundError: org/apache/http/nio/client/HttpAsyncClient
```

## Fix

`ReflectionUtil.newInstance` rethrows the `LinkageError` cause of the
`findConstructor` failure, except for the `NoSuchMethodError` and
`IllegalAccessError` that come with a missing or inaccessible
constructor (those are still reported as `NoSuchMethodException` /
`IllegalAccessException`). This brings back the `Class.newInstance()`
behaviour for every caller, including the OSGi info managers. One case
stays different: a link failure that is itself an `IllegalAccessError`
(a dependency that cannot access its superclass) cannot be told from an
inaccessible constructor, so it is still reported as
`IllegalAccessException`. `Class.newInstance()` threw the raw
`IllegalAccessError`. The managers catch neither, so the scan fails in
both cases.

## Test plan

- [x] New
`ReflectionUtilTests.newInstanceThrowsLinkageErrorOfClassWithMissingDependency`:
a class loader that cannot load one dependency, so the class fails to
link. Before the fix the test fails with the same
`IllegalAccessException: no such constructor`
- [x] New
`ReflectionUtilTests.newInstanceFailsOnInaccessibleConstructor`: a
private constructor seen through `publicLookup()` still fails with
`IllegalAccessException`, not with a raw `IllegalAccessError`
- [x] New `ReflectionUtilTests.newInstanceFailsOnInaccessibleClass`: a
package-private class seen through `publicLookup()`, which
`findConstructor` reports without a cause, still fails with
`IllegalAccessException`, not with a `NullPointerException`
- [x] New
`LocalConnectorInfoManagerTests.testSkipsConnectorWithUnlinkableConfiguration`:
a bundle with two connectors, the configuration class of one refers to a
class missing from the bundle; the scan lists the other connector.
Without the fix it fails with the `IllegalAccessException: no such
constructor` from OpenIDM#259; without the `catch
(NoClassDefFoundError)` in `LocalConnectorInfoManagerImpl` it fails with
the `NoClassDefFoundError`. The test closes the bundle class loader
before it deletes the temp jar, which Windows cannot delete while it is
open
- [x] `connector-framework`: 205/205 pass (incl.
`newInstanceFailsWithoutNoArgConstructor`, which still gets
`NoSuchMethodException`); `connector-framework-internal`: 525 run, 0
failures, 2 skipped (`testConfigurationUpdate` of the remote manager
tests)
- [x] End to end: with this `connector-framework` installed locally,
OpenIDM `openidm-provisioner-openicf` on openicf 2.1.0-SNAPSHOT passes
138/138 (same as on 2.0.4; without the fix `beforeTest` fails)

…operties (#271)

Part of #267
Fixes #269
Fixes #270

## Problem

A managed object property marked as "Nullable" gets a type array:
`SchemaUtils.setNullableProperties` in the Admin UI turns its `type`
into `[type, "null"]`. For a relationship this is `["relationship",
"null"]`, and for a relationship collection `["array", "null"]`. Three
places did not read these type arrays:

- #267: `ManagedObjectApiDescription.build` read the type of a
relationship property, and of the items of a relationship collection,
with `asString()`. It failed with `/type: Expecting a java.lang.String`,
and the managed object was left out of the API description.
`ReverseRelationshipValidator` then fell back to `NA` and skipped the
singleton and duplicate-assignment checks.
- #269: `SchemaField.initializeType` followed `items` only for the
string `"array"`. A Nullable relationship collection became a core
field: no relationship provider, its value stored inside the managed
object, the reverse property not kept in sync.
- #270: the Admin UI finds relationship properties by comparing their
type with `"relationship"` and `"array"`. The edit view did not read the
value of a Nullable singleton relationship, the relationship widget left
Nullable relationships out, and the linked view and the default value
editor of a mapping to such a property threw `Unknown editor for
schema`.

## Change

- `ManagedObjectApiDescription.build` tells a singleton from a
collection by `SchemaField.isArray()` of its relationship provider.
`replaceRelationshipType` replaces `"relationship"` with `"object"` in a
type string or a type array, so `["relationship", "null"]` becomes
`["object", "null"]`. The types of a type array stay unique: `["object",
"relationship"]` becomes `["object"]`.
- `ReverseRelationshipValidator.parseReverseReferenceType` accepts a
type array that lists `"array"` or `"object"`.
- `SchemaField.initializeType` reads a type array of `"array"` and
`"null"` with a typed `items` schema like `"array"`. Without one it
stays a core field, as before: no `items`, an `items` schema without
`type` such as `{}` or `{"$ref": …}`, a tuple of `items` schemas, an
`items` type that is not a string or a list of strings or that lists
only `"null"`, or an `items` schema of type `"array"` without a typed
`items` schema of its own. A type array that lists another type next to
`"array"` is not changed either.
- `ResourceDelegate.normalizeRelationshipTypes` reads `["relationship",
"null"]` as `"relationship"`, and `["array", "null"]` with relationship
items as `"array"`, in the schemas that `ResourceDelegate.getSchema`
(with `allSchemas`) and `AdminUtils.findPropertiesList` return. Both
work on the copy that `ConfigDelegate.readEntity` returns, so
`managed.json` keeps the type arrays. A property that is not an object,
such as `null`, is skipped, so it does not stop `getSchema` for every
managed object.

## Upgrade note

A relationship collection marked as Nullable before this change is a
relationship collection again after the upgrade. The values written to
it while it was a core field are no longer returned, and the next update
of the object does not keep them inside it. The relationships stored
before it was marked as Nullable are returned again. See the upgrade
note in #269 for how to keep the values.

As for any relationship collection, a PATCH `remove` of the whole field
without a value, and a `move` or `copy` onto it, now fail with `400
Cannot delete collection`. While the field was a core field they
succeeded. A `replace` with `null` is rejected by the PATCH parser,
before and after this change.

A rollback to a release without this change makes such a field a core
field again. The relationships written to it after the upgrade are then
no longer returned for the object that holds the field, while a reverse
property on the other object that is not Nullable still lists them, and
the next update of the object stores the value inside it again.

An older copy of
`org/forgerock/openidm/ui/common/delegates/ResourceDelegate.js` in
`ui/admin/extension` overrides the new file and has no
`normalizeRelationshipTypes`. `AdminUtils.findPropertiesList` then
fails, and the mapping, assignment, self-service and resource-collection
views get no properties. Re-apply such customizations to the new files,
as "What You Should Do With Your UI After Updating" in the update guide
describes.

## Dependency

The OpenAPI transformer still has to describe the type arrays
`["object", "null"]` and `["array", "null"]`. That is
OpenIdentityPlatform/commons#382, which reaches OpenIDM through
OpenDJ#1243, OpenICF#210 and #259. Until then `build` still drops the
API description of a managed object with a Nullable relationship, now in
the transformer, and `ReverseRelationshipValidator` still falls back to
`NA`. This pull request is therefore only part of #267, which #259
closes. The `SchemaField` and Admin UI parts do not depend on it.

Once OpenIDM resolves the fixed transformer,
`testBuildReplacesRelationshipTypes` also gets rows with
`["relationship", "null"]` and with `["array", "null"]` and relationship
items, which expect `["object", "null"]` and `isRelationship: true`.
Until then no test can tell `build`'s `isArray()` selector from the old
type comparison: every type array makes `build` return `null` in the
transformer.

## Tests

- `openidm-core`: 143 tests, 0 failures. With the old
`ReverseRelationshipValidator` and `SchemaField`, exactly the new
type-array rows fail. With the `items.get("type").isNotNull()` check of
the previous round in `SchemaField.isArraySchema`, exactly the 6 new
rows with an unreadable `items` type fail. Without the check for a type
besides `"null"` in `hasTypedItems`, exactly the 2 rows `[]` and
`["null"]` fail; without its recursion into an `items` schema of type
`"array"`, exactly the 2 array-of-arrays rows fail. With `get(0)`
instead of `contains` in `hasType`, exactly the 2 rows that list
`"null"` first fail. Without the de-duplication in
`replaceRelationshipType`, the `["object", "relationship"]` row fails.
- `openidm-ui-admin` (with `openidm-ui` and `openidm-ui-common`): eslint
clean, 132 QUnit tests, 0 failures; with the old `ResourceDelegate.js`
and `AdminUtils.js`, exactly the 3 new tests fail. They compare with
`strictEqual`, so a normalization that leaves a one-element array such
as `["relationship"]` fails all 3 of them as well. Swapping the two
blocks of `normalizeRelationshipTypes`, dropping its `items` guard in
the collection branch, or dropping the filter of properties that are not
objects, fails the `normalizeRelationshipTypes` test.
`openidm-ui-enduser`: 2 tests, 0 failures.

## Summary

Code scanning: two Trivy findings on the build that no upstream bump
covers. #259 handles the ones that come through the OpenICF BOM.

| Library | Was → now | Comes from | Alerts |
|---|---|---|---|
| `xerces:xercesImpl` | 2.9.1 → 2.12.2 | `http-builder` 0.7.1 →
`nekohtml` 1.9.16, copied to `lib/` (the `groovy.classpath` in
`conf/script.json`) | #941 (CVE-2012-0881), #942 (CVE-2013-4002) |
| `at.yawk.lz4:lz4-java` | 1.10.1 → 1.11.4 | `orientdb-core` 3.2.51,
embedded in the `openidm-repo-orientdb` bundle | #976 (CVE-2026-106451)
|

Both versions are managed in the root `dependencyManagement`, next to
the MyBatis override, and set through properties. With xercesImpl
2.12.2, `lib/` ships xml-apis 1.4.01 instead of 1.3.04. 1.11.4 is the
fixed lz4-java version Trivy reports; even OrientDB 3.2.57 only moves to
1.11.0, so an OrientDB bump alone would not be enough.

Maven Enforcer rejects resolved xercesImpl versions below 2.12.2 and
lz4-java versions below 1.11.4 across the reactor. The override comments
identify when to reassess them, and `legal/THIRDPARTYREADME.txt`
reflects the new Xerces and xml-apis versions and their NOTICE copyright
years.

Only the build scans report #976, so it closes with this PR. The scans
of the published 7.1.2 images also report #941 and #942, as well as #979
(lz4 in the 7.1.2 image); those stay open until the next release image
is scanned.

## Test plan

- [x] `mvn dependency:tree` across the reactor: only
`openidm-repo-orientdb` (lz4-java) and `openidm-zip` (xercesImpl,
xml-apis) are affected; they now resolve 1.11.4, and 2.12.2 with 1.4.01
- [x] Before the review changes, clean full `mvn -U clean verify`
locally on JDK 27: 49/49 modules, no test failures
- [x] Before the review changes, `openidm-repo-orientdb` manifest
compared against a build with `-Dlz4.version=1.10.1`: only the jar name
in `Bundle-ClassPath` and `Embedded-Artifacts` changes; `Import-Package`
is identical
- [x] Before the review changes, built zip started locally with the
default OrientDB repository (`plocal`, embedded server): `OpenIDM
ready`, no SEVERE; a managed user created, queried and deleted over REST
- [x] Before the review changes, the `lib/` jars of the zip run both
http-builder parser paths (the nekohtml `SAXParser` with the
xml-resolver `CatalogResolver`, and JAXP `SAXParserFactory`): the same
elements and the same `org.apache.xerces.jaxp.SAXParserFactoryImpl` as
with xercesImpl 2.9.1
- [x] After the review changes, `mvn -o validate` passed for all 49
modules. Overriding Xerces to 2.9.1 and lz4-java to 1.10.1 separately
made Enforcer fail on the corresponding dependency.
- [ ] Full build in CI
- [ ] Trivy on the build no longer reports #941, #942, #976